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We present an inference system for a version of the ;r -calculus in Haskell for the session type pro- 
posed by Honda et al. The session type is very useful in checking if the communications are well- 
behaved. The full session type implementation in Haskell was first presented by Pucella and Tov, 
which is 'semi-automatic' in that the manual operations for the type representation was necessary. 
We give an automatic type inference for the session type by using a more abstract representation for 
the session type based on the 'de Bruijn levels'. We show an example of the session type inference 
for a simple SMTP client. 



1 Introduction 

The Session-type system (6] provides a way to statically check communication protocols. Incorporating 
session types in the existing programming languages eases the communication centric programming in 
that session typed components are guaranteed to behave correctly by their types. However, it is not 
apparent how to integrate the session typing discipline with the existing programming languages. 

Several session-type implementations fT3l [T6l [TTl have been proposed for Haskell. The type-level 
programming is shown to implement session types. It is natural to use the functional dependencies lIHl 
for encoding the duality of session types. The indexed monad HI HI is used to propagate the session-type 
information through process constructs. 

Currently, all existing implementations |[T3l[T6l[T7]| of the session type implementation require some 
manual annotation in program code to infer types. The session types in [,13J and [17| often make even 
a simple program to be unnecessarily verbose. The typechecking in |[T6l requires incomprehensible 
annotation when the number of channel increases. A fully- automatic type inference is essential as seen 
in other typed frameworks such as parser combinators [12] and database access f3l. 

Our goal is to provide a fully-automatic session-type inference in Haskell. We extend the work by 
Pucella and Tov [161 to infer types without manual operations. We show an implementation technique 
for the original session-type system O as the target language. 



The issue of type-level representation The common idea in fTF] and lIlTl is to track session types 
for multiple channels using the extra symbol table embedded in the Haskell's type. The inferred Haskell 
type for a process would be P {c\ ^ s\;c2^ S2,- • •} where P is a process type constructor and {• • •} is 
the symbol table to assign each channel a to its session type Si. This symbol table is represented in the 
type-level, hence the channels c,- is not a value, but a type which reflects an identity of a channel. 

In the implementation in 1 16], type variables represents channels in a symbol table. To distinguish 
them from each other, such type variables are locally quantified at the position the channels are intro- 
duced. Such a type variable is matched against the symbol table every time a type inference rule is 
applied. Since the symbol table itself can only be represented as a type-level list of key-value pairs. 
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matching on channels is unavoidable. But in the Haskell type-level programming, such matching opera- 
tion is not provided. 

To alleviate this difficulty, [16] devises the stack manipulation dig and swap on a symbol table for 
reordering. The stack restricts the communication primitives only to the first entry of the symbol table, 
swap swaps the first entry of the symbol table with the second one. dig p allows p to access on the 
second entry of the symbol table. 

In 1 16], it is stated that the automatic application of these operations is not possible without adding 
extra information in the symbol table and the answer for this problem is not shown. 

Main idea To resolve the type matching problem, we use the natural number based on de Bruijn level 
as the type-level representation for channels. The symbol table is represented as just the type-level list of 
session types, and accessed by the numbers. As the number-based access on the type-level hst is possible 
in the existing technique ifTOll . type inference is fully automatic. 

Our main contribution is to show an automatic inference of the session-type inference in Haskell. 
Although in [16] only the capability passing is possible, our calculus is possible to pass a channel. 
To show that our improvement is purely in the sense of matching, It is shown that by extending typing 
discipline in [ 16 1 it can have the same expressiveness as ours. 

Related work Neubauer and Thiemann [13 ] implemented session types on a single communication 
channel in Haskell. Their implementation avoids aliasing by prohibiting explicit use of a channel. 

Pucella and Tov |161 have shown a general technique to encode session types in languages like 
Haskell, ML, and C#. Their implementation based on manual stack manipulations swap and dig liberates 
from type-level programming which is only available in Haskell, hence their technique can be applied to 
other languages which have parametric or generic types. On the other hand, their implementation cannot 
enjoy fully- automatic type inference. 

The implementation proposed by Sackman and Eisenbach lITTl supports full functionality of session 
types. However, their library requires a manual construction of session types. There are trade-offs 
between such a manual handling and annotated type-inference approach in that while type-inference 
reduces unneeded annotations, explicit annotation with a rich set of syntax increases readability and 
expressiveness of types. We will discuss this aspect in the later section. 

The difference of our implementation from the previous work is summarized in the following table. 





channel 


annotation 


portable 






passing 




Neubauer et al. IJ3J 


no 


auto 


no 


Pucella et al. |[T6l 


yes in a limited contexj^ 


stack based channel handling 


yes 


Sackman et al. ifTTl 


yes 


manual construction of session types 


no 


Our implementation 


yes 


auto 


no 



Paper Organization The rest of this paper is organized as follows. In Section |2] session types and the 
TT-calculus is introduced from |6]. In Section|3} we show the session-type inference in Haskell, and com- 
pare it with other implementations. We describe an example of a SMTP client using our implementation 

'a working implementation, full-sessions , which can be compiled by the Glasgow Haskell Compiler 6.10.2 or higher 
is available at: http://hackage.haskell.org/package/full-sessions/ Typing cabal install full-sessions in 
a shell will install full-sessions in your environment. 

^See section 5 
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in Section |4] In Section [5j we show that our implementation is more expressive than |[T6l in the aspect of 
channel-passing and show the way to extend [16] to have the same expressive power as ours. In Section 
[7] we discuss a few aspects of usability of session-type implementation. Finally, Section[8]concludes the 
paper. 



2 Session types and the ;r-calculus 
2.1 The ;r-calculus 

The syntax of our Ti-calculus processes is defined by the following grammar: 

P ::= sender c e P \ recvji c {Xx.P) \ sell;i: c P \ se\2ji c P \ offer ji c P\ P2 
I sendS;i: c c' P \ recvSji c {Xc' .P) \ P \ \\ Q\ inact;^ | new^i; (Xc.P) 

We use A -abstraction to represent bindings using higher-order abstract syntax fT4\. x ranges over vari- 
ables of basic values and channels, c and c' range over channels, and P and Q range over processes. We 
put the subscript n on each process constructor since they are overloaded in the later sections. 

An input process recv;i: c (Xx.P) inputs a value via channel c, then binds it to x in P. An output 
process send;;: c e P first evaluates e, then emits the value via channel c, and becomes sell;^ c P 
and sel2;r c P denote the selection of branch label 1 or 2 on c. It first sends the selected label, and 
becomes P. offerer c Pi P2 receives a label. Then it becomes Pi or P2, depending on the received 
label. sendS;i: c c' P sends channel c' on c and becomes P. recvS^r c {Xc' .P) receives a channel on 
c, binds it to c' in P, and becomes P. These operations enable higher-order session communications. 
P III 2 runs P and Q concurrently, inact^j is the constant to denote the terminated (inactive) process. 
new;r (Xc.P) generates a fresh channel c bound in P. 

The operational semantics of the TT-calculus is in Figure[T] Here, e \,v represents that e is evaluated to 
a value v. The structural congruence of processes is in Figure |2] The function in{P) denotes free names 
in P. =a denotes a -equivalence. 

e Iv 

Com 



send;j c e P 1 1 1 recv;j c (Xx.Q) — > P \ \\ Q{v/x} 



LABELi : 3211^ III ofier^cQi Qi ^ P \\\ Qi 
LABEL2 : gg-L2^ c P \\\ of fer^ c Qi Q2 ^ P \\\ Q2 



Pass : 



sendS;r c c' P 1 1 1 recvS;r c {Xc .Q) — ^ P 1 1 1 2 



P — yP' P — >P' 

Scop : Par 



new;r (Xc.P) — yne^j, (Xc.P') P \\\ Q — ^P'lllG 

P = P' A P' — y Q' /\ Q' = Q 

Sir : 

P ^ Q 



Figure 1 : The operational semantics of the Ti-calculus 
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P=QifP=aQ P|||inact = P P\\\Q = Q\\\P neu^r (Ac.inact) = inact 
(P||| Q) \\\R = P\\\ {Q\\\R) new;, (Xc.P) \\\ Q = ne^^ (Ac.P ||| Q) ifc0fn(e) 

Figure 2: Structural congruence of the Ti-calculus processes 



2.2 Session types 

In this subsection and following subsection, we review a session type system in [6|. 

A session type represents a protocol which is associated with an endpoint of a channel, v ranges over 
types for basic values, and u ranges over session types. The session types in this paper are defined by the 
following grammar: 

u ::= Send v u \ Recv v u \ Select ui U2 \ Offer u\ U2 
I Throw Ml U2 I Catch u\ U2 \ End | Bot 

Send V u denotes a protocol to emit a value of type v followed by a behavior of type u. Recv v u 
denotes a protocol of receiving a value of type v followed by a behavior of type u. Select u\ U2 denotes 
to be either behavior of type ui or type U2 after emitting a corresponding label 1 or 2. Of f er mi U2 
denotes a behavior like either u\ or U2 according to the incoming label. Throw ui U2 denotes a behavior 
to output of a channel with session type u\ followed by a behavior of type U2- Catch ui M2 is the input 
of a channel with session type u\ followed by a behavior of type U2. End denotes a terminated session. 
Bot is the type for a channel whose endpoints are already engaged by two processes, so that no further 
processes can own that channel. For example, in (send;;: c e inact ||| recv;, c (A;c.inact)), c has the 
session type Bot. 



A session type u has the dual u. The definition of dual is illustrated in Figure 3.2.2 A dual of a 
session on one end of a channel is the session on the other end of the same channel. 



Send V M = Recv v m Select mi M2 = Off er mi M2 Throw mj M2 = Catch M1M2 



Recvv M = Send V M Of f er mi M2 = Select mi M2 Catch M1M2 = Throw wi M2 
End = End Bot = undefined 



Figure 3: Duality for session types 



2.3 The typing rules 

In the session-type system f6l, there are two kinds of type judgments, value judgment Y \- e>v and 
process judgment F h P^ A. A process P is typeable if there exists some F, A such that F h Po A. F 
denotes sorting that maps variables to types of basic values. A denotes session type environment or 
session typing that maps names to session types. A completed type environment is the one that assigns 
the type End to every name appearing in a process. 

A process is typeable under F, iff F h P A for a given A. A typeable process never fails due to 
communication mismatch. 

The typing rules are defined in Figure [i] The composition of type environments A© A' is defined by 
the component-wise extension of the type algebra which is defined as follows: 
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End ®u = u M © End = u 

u(Bu' = Bot if M = m' otherwise undefined 

The Uterature ||6l defines an erroneous process using following notions: A c-process is a process 
prefixed by subject c, such as send;^ c e P and recvS^j: c {Xc' .P). A c-redex is the parallel composition 
of two c-processes in either of form send;;: c e P \ \\ recv^i c {Xx.Q), sel,- c f ||| offerer c Qi Q2 for 
i€ {1,2}, or sendS;r cc'P ||| recvS^r c (Xc'.Q). 

Definition 1 (Error) We shall say that P is an error ifP = new;j (Ac. 2 | R) where Q is, for some c, the 
parallel composition of either two c-processes that do not form a c-redex, or three or more c-processes. 

Then we quote the following theorem, which is also valid for our framework, from f F| |^ 
Theorem 1 (Type Safety) A typeable program never reduces to an error. 



Y^e>v rhPoA-ciM r,x:vhP[>A-c:M 

[Send] [Rev] 



r h sender c e P\>h-c: Send v u TV- recv^j c (Ax.P) > A • c : Recv v u 

P>^■c■.Ul P^>^■c■.Ui Y^ Qi>\-c:u2 

[Sel] [Br] 



r h seller c P>A - c : Select u\ U2 T h offerer c P Q\>l^-c : Offer u\ U2 

rhP[>A-c : U2 



Y h sendS;r c c Po A • c : Throw u\ U2-c : u\ 
Y h PoA -c : U2tC : u\ 



[Thr] 



r h recvS;r c {Xc' .P) > A • c : Catch ui U2 



[Cat] 



rhPi>A YhQ[>A' rhP>A-c:Bot A completed 

[CONC] ^ [CRES] [INACT] 

rhP|||e>A©A' rhnew;j (Ac.P)oA rhinactt>A 

Figure 4: Typing rules for session types 



3 Session-type inference on Haskell 

We first introduce concurrency primitives in our implementation using the ;r-calculs defined in the Sec- 
tion 2. 1. Then we present a few techniques to embed session types in Haskell as in 1 13] and [16]. Finally 
we show the session type reconstruction for multiple channels based on de Bruijn levels. 

3.1 Concurrency primitives and session types in full-sessions 

Our implementation, full-sessions , provides concurrency primitives using monad rather than the 
syntax provided in the Section 2. This is because monad is the most well-known way to describe com- 
municating processes in Haskell. 



To show this we do not require type preservation, as stated in (5|. 
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To keep connection between the original session-type system with our implementation, we show our 
primitives using continuation monad. The behaviour of each primitives is captured by the continuation- 
passing monad of type ( (a -> Pi di) -> Pi d2) where Pi d, corresponds to the type of process term P 
in Section 2.1, and d, is a type-level representation of a session-type environment A. The meaning of each 
primitives are summarized in the Table [T] In the table we abuse the A -notation of hoas syntax in Section 
2 to represent a syntactic function from values or channels to processes, k ranges over continuations of 
type a -> Pi dl. For readability, we use the ixdo notation [16], which provides a syntactic sugar to 
write programs in an imperative style. For example, the term ixdo send c e; recv c and ixdo fork 
(send c e) ; recv c are interpreted as Xk.sendji c e {recvj^ c k) and Xk.[i:ec^ji c k \\\ send;;: c e), 
respectively. 

Processes can be run using the function runS. runS p runs a TT-calculus process /^(A-.inact;^)- Here- 
after we call the all primitives in Table[T]as a session of type Session. 





Function 


Meaning 


Channel Creation 


new 


Xk.nevjt k 


Value Output 


send c e 


A^.send;/!: c e {k ()) 


Value Input 


recv c 


Xk.icecv-,1 c k 


Selection 


seli c (/ e {1,2}) 


Xk.seliji c [k ()) 


Offering 


offer c pi p2 


Xk.offer-ji c {pi k) {p2 k) 


Session Delegation 


sends c c' 


Xk.seBASn c c' {k ()) 


Session Reception 


recvS c 


Xk.recvSji c k 


Fork 


fork p 


Xk.{{k 0) III [p (l_.inact;,))) 


Calling Haskell I/O 


±0 m 


(Execute Haskell's 10 action m and pass the result to the continuation) 


Recursion of a session 


recurl / c 


Xk.f c k (Recursive call of a session (/ c) where c is a channel) 


Recursive use of a channel 


unwind c 


Xk.k (Unwind a recursive session type 
Rec n u into M[Var n i— > Rec n m] on c 



Table 1: Primitives in the full-sessions library 



3.2 Session type inference for a single channel 
3.2.1 A single-threaded participant 

Let us begin with a case of single channel in a single-threaded participant. In such a case a session type 
advances as a session proceeds. For example a type Send Int End advances to End when a channel of 
that type is used to send an integer. To track such an advance of a session type, we assign a pair of session 
types, called a pre-type and a post-type, to each occurrence of a channel. A pre-type denotes the session 
type before a session starts. Similarly, a post-type is the session type after a session ends. 

In many cases post-types act as a placeholder, which allows concatenation of two session types. 
For example, consider one of the simplest sessions, send c True. The pre-type of the channel c in this 
session is Send Bool u and the post-type of it is u, where m is a type variable. This means that another 
session which uses the channel c can be further concatenated after this session. 

The concatenation of two session types are done by unification. In a concatenation s\\s2 of two 
sessions, the post-types of channels in si is unified with the pre-types of ones in S2- The pre-types of 
channels in the concatenated session s\ ;s2 is same as the ones in s\. The post-types of channels in s\ ■,S2 
is the ones of 52- Accordingly, (send c True; send c "abc") has (Send Bool (Send String M2)) as 
the pre-type and U2 as the post-type on the channel c, where U2 is a type variable distinct from u. 

For a more complex example, the code below describes a simple calculator server. 
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server c = ixdo x ^ recv c ; y -s— recv c; offer c (send c (x+y::Int)) (send c (x<y)) 

The server firstly receives two values of type Int and a branch label (here the label is either 1 or 2), then 
sends an answer either of type Int or of Bool according to the label. 

The pre/post-type of the channel c in the server can be inferred by the GHC's typechecker via aux- 
iliary function channeltypel. By showing the type of (channeltypel server) using GHC's interactive 
environment, users will obtain the following response: 

prompt> :t chcLnneltypel server 

channeltypel server :: (Recv Int (Recv Int (Offer (Send Int a) (Send Bool a))), a) 
3.2.2 Duality of two session types 

The fork primitive requires the duality between pre-types of two sessions. Here we explain it by using 
the previous example of a calculator server. Firstly, a client of the server would be like this: 

client c — ixdo send c 123; send c 456; sel2 c; ans -S— recv c; 

io (putStrLn (if ans then "Lesser" else "Greater or Equal")) 

The pre-/post-type of c in client is (Send Int (Send Int (Select ui (Recv Bool m))) and u, re- 
spectively. By putting server and client in parallel by fork, and by generating a channel by new, we 
obtain the code below: 

calc c = ixdo fork (server c) ; client c; 
startCalc = ixdo c ■;— new; calc c 

The above code typechecks because the two usages of c in client and server are dual. The resulting 
pre-type is Bot, as the session-type algebra of ||6l implies. The post-type is End since fork requires the 
usage of channels in the given session to be ended. Here we confirm it: 

prompt> :t chsmneltypel calc 
chcinneltypel calc :: (Bot, End) 

A session can be run by the function runS. Typing runS startCalc will produce the result "Lesser" 
on the console. The following is the result of the execution using the interpreter: 

prompt> runS startCalc 
Lesser 

3.3 Tracking sessions with multiple channels by De Bruijn indexing 

To track usages of multiple channels in type-level, a natural number of de Bruijn level is assigned to each 
channel. De Bruijn level represents the nesting depth of a variable binder. For example, in a A -calculus 
term Xx.Xy-x the level of the variable x is whereas y is \. Figure |5] shows the de Bruijn level indexing 
of a session. In the figure, the de Bruijn level of a variable is denoted by a superscript at the binding 
position. Note that we need to count on only channels, hence each variable c,d,e and / have an index 
but X does not. 

De Bruijn levels are assigned to the type of channels. A channel has the type of the form Channel 
t n where « is a de Bruijn level of the channel and ? is a "type-tag" 1 1 1 1. We do not explain the type- 
tag, since it is out of scope of our paper. Natural numbers are represented by combinations of the two 

*Such discipline can also be observed in session-type systems equipped with a thread- spawning construct, the "ended" 
condition of Spawn rule in ID. 
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n n+1 

ixdo c <— new; d <— new; 

11+2 

fork (ixdo e <-catch c; ...) 
X <- recv d; 

11+2 

f «— catch d; 



Figure 5: De Bruijn Zeve/ indexing in a session 



types representing peano-numerals Z and S n where each of them denotes and n + \ respectively. For 
example, a channel which has de Bruijn level 2 has type Channel t (S (S Z)). Each number points to a 
certain position of a type environment. 

Session types of multiple channels are recorded in extra type environments. We need two type en- 
vironments for pre-types and post-types. Hereafter we call them pre-environment and post-environment, 
respectively. 

Such an environment is represented by a list of session types, and its elements are accessed by 
specifying the number of de Bruijn level. Figure [6] is an example of a session send c "abc"; send 
d True and its pre-/post-environment. Assuming that c and d have (Haskell-) type Channel t Z and 
Channel t (S Z) respectively, the pre- and post-environment of the session is inferred as shown in the 
figure, c and d has pre-type Send String mi and Send Bool U2, and post-types of them are mi and U2, 
respectively. Note that the figure also depicts the session- types in an intermediate step after send c 
"abc". In that state, c has type mi and d has type Send Bool m2. 

(Assuming that c :: Channel t Z and d :: Channel t (S Z)) 



ixdo 
send c "abc" ; 
send d True; 



Send String ui 



Send Bool U2 



pre- 
environment 



Send Bool U2 





U1 


U2 



post- 
environment 



0th element 1st element 

a session (Haskell term) Inferred Session Types (Type-level lists) 



Figure 6: Tracking session types by numbers 



The type of a session has the form of Session t ss tt a. The pre -/post-environments are at the position 
of ss and tt respectively. The parameter a is the type of a value returned by a session, and t is a type-tag. 

The pre-/post-environments ss and tt are actually represented by type-level lists lITOl . A type-level list 
is either ss :> u or Nil, where ss is another type-level list and m is a session type, and Nil is a empty list. 
Note that the type constructor : > is left-associative, for example ss ■.>a:>b is interpreted as (ss :>a) : >b. 
Also note that the type environment is counted from left to right order. For example, the 0-th element of 
]i±l:>a:>b:>c is a. 

Provided that the type of c is Channel t Z and the type of d is Channel t (S Z), a session of the 
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previous example (send c "abc"; send d True) has type Session f (Nil:>Send String ui:> Send 
Bool M2) (Nil:>Mi :>M2) ()■ 

In general, the de Bruijn levels can be a non-constant value, like n + 1, « + 2 and so on. For example, 
if the length of a session-type environment ss is «, and the type of c and d is Channel t n and Channel t 
(S «) respectively, a session (send c 1; send d True) has type Session t (5i:>Send Int u\:> Send 
Bool M2) {ss:>ui :>U2) (). Constraints for the length of a session-type environment is represented in 
the type-level by the type-class SList ss n, which represents that the length of ss is n. Observe that 
the existence of the placeholder ss in each of session-type environments. This makes possible to han- 
dle arbitrary numbers of channels by concatenation of sessions which introduce new channels, which 
involves unification between the post-environment of the earlier session and the pre-environment of the 
later session. 

When a new channel is introduced, post-environments are extended to store the session type of the 
introduced channel. The primitive new and catch involve such a mechanism, new has pre-environment ss 
and post-environment ^.s- : >Bot . At the same time new returns a channel of type Channel t n, where n is 
equal to the length of ss and points to the leftmost position of the post-environment, namely Bot. Hence 
the index of a generated name is assured to be fresh. 

Figure |7] shows the pre-/post-environments of a session (c new; fork (send c True)). The 
post-environment has an extra entry for the newly created channel. The post-type of the newly created 
channel is dual of Send Bool End, which is required to communicate with the forked session. 



ixdo 
c *- new; 



ss 



fork (send c True); 



pre- 
environment 



Bot 









Recv Bool End 



SS :> Recv Bool End 

a session (Haskell term) Inferred Session Types (Type-level lists) 



post- 
environment 



Figure 7: Extension of a type environment by new operation 



Similarly, catch c has the pre-/post-environment ss and tt : >u', where n-\h element of ss is Catch u' 
u and that of tt is u. Figure [8] shows such use of catch and the inferred session types. 

3.4 Comparison of existing Haskell implementations of session types 

Our encoding based on de Bruijn indexing reduces most of annotations which are required in the other 
works. We show that by giving a few examples of sessions. 

Stack-based implementation The implementation by Pucella and Tov fW\ applies a stack of session 
types as the representation of a type-environment. Communication primitives can only access the top of 
the stack, hence explicit manipulation of stack is required. The combinator dig and swap is provided for 
such purpose. The swap combinator swaps the top two channels on the stack. On the other hand, dig 
combinator converts a given session to operate on a deeper channel stack. Provided that the session type 
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ixdo 

d <— catch c; 
send d True; 









Catch (Send Bool End) ui 


pre-environment 








Ul 


Send Bool End 









Ul 


End 



post-environment 



a session (Haskell term) Inferred Session Types (Type-level lists) 

Figure 8: Extension of a type environment by catch operation 



for c and d is on the top of the stack in this order, the code below is equivalent to (send c "abc" ; send 
d True): 

ixdo send c "abc"; swap; send d True 

or 

ixdo send c "abc"; dig (send d True) 

As a number of channels increases, more stack operations will be required. In 1 16] a few approaches to 
this problem are discussed, however the problem had been left open, and our number-based approach is 
not covered. 



Manual construction of session types The implementation by Sackman and Eisenbach |T7l provides 
a very rich set of communication primitives, at a cost of manual construction of session types. There 
are two communication media, channels and Pids. We show the simplest case of communication via 
Pid. The example below passes an integer 10 to the other thread and terminates. It is equivalent to runS 
(ixdo c <- new; fork (send c 10); recv c). 

(s, a) = makeSessionType ( 

newLabel ~»= Aa — > 

a .= send (undefined : : Int) ~>> end 
~>> sreturn a) 

p = run s a (ssend 10) srecv 

Here makeSessionType returns a collection of session types s and its fragment a. In the argument of 
makeSessionType the construction of a session type is described procedurally. Again, as a number of 
threads with different protocol increases, the more construction of session types will be required. The 
case of channel-based communication is similar. 



4 An example SMTP client 

We show the network functionality of the full-sessions by the example of a SMTP client with mul- 
tiple channels. A single-channel version of SMTP client with session types has its origin from [13|. 

Table |2] shows additional primitives for network communication. To model network protocols, the 
type-based branching, sel/N and of f erN, is provided in addition to the previous label-based branching. 
Note that the sel;N does nothing, but we need them to infer the session types for type-based selections. 
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Syntax 


Meaning 


Connect to a service 
Type-based offering 

Selection annotation 


c connectNw s 
offerM c pi p2 

seim c (j'e {1,2}) 


Connect to a service s and bind a session channel to c 
Offer two receiving session pi and p2 on c 
Determine which branch of Select ui U2 will be 

selected on c 



Table 2: Additional primitives for network programming 



Here we show our implementation of SMTP client in the simplest form. Firstly, the types for SMTP 
commands and replies are defined as follows: 

— Types for SMTP commands, 
newtype EHLO = EHLO String 
newtype MAIL = MAIL String 
newtype RCPT = RCPT String 
data DATA = DATA 

data QUIT = QUIT 

newtype MailBody = MailBody [String] 

— Types for SMTP server replies (200 OK, 500 error and 354 start mail input) 
newtype R2yz = R2yz String; newtype R5yz = R5yz String; newtype R354 = R354 String 

To deal with the stream-based communication of TCP, either a parser or a printer for each type of com- 
municated values must be prepared. Provided such functions exist, the SMTP client is described as 
follows: 

— auxiliary functions 

send_receive_200 c mes = ixdo send c mes; (R2yz _) <s— recv c; ireturn () 
send_receive_354 c mes = ixdo send c mes; (R354 _) recv c; ireturn () 



sendMail c d = ixdo — the body of our 1 
(R2yz _) ^ recv c 

send_receive_200 c (EHLO "mydomain") - 
unwindO c 
sellN c 

from recv d 

send_receive_200 c (MAIL from) 

unwindl c 

sellN c 

to ^ recv d 

send c (RCPT to) 

offerN c (ixdo 

(R2yz _) recv c 

sell d; mail recv d 

unwindl c 

sel2N c 

send_receive_354 c DATA 
send_receive_200 c (MailBody mail) - 
unwindO c 
sel2N c 

send c QUIT; close c 
) (ixdo 



[TP client 
receive 220 

send EHLO, then receive 250 
(annotation) unwind a recursion variable 
(annotation) branch to send 'MAIL FROM' 

— (1) input the sender's address on d 
send 'MAIL FROM', then receive 250 
(cinnotation) unwind a recursion variable 
(annotation) branch to send 'RCPT TO' 

— (2) input the recipient's address on d 
send 'RCPT TO' 

branch the session according to the reply 
if 250 OK is offered 

— (3) input the content of the mail on d 
(cinnotation) mwind a recursion variable 
(annotation) branch to send 'DATA' 

send 'DATA' and receive 354 
send the content of the mail 
(annotation) unwind a recursion variable 
(cinnotation) branch to send 'QUIT' 
send 'QUIT' and close the connection 
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(R5yz errmsg) ^ recv c; 
sel2 d; send d errmsg; 
send c QUIT; close c) 



— if 500 ERROR is offered 



— (4) output the error message on d 
— send 'QUIT' and close the connection 



close d 



The sendMail takes two channels c and d as its parameters. The former is used to communicate with the 
SMTP server while latter is used to prepare necessary information for sending a mail. By checking the 
type of typecheck2 sendMail, the following type is answered by GHC: 

typecheck2 sendMail :: (SList ss 1, IsEnded ss bl) Session t 
(ss :> Recv R2yz (Send EHLO (Recv R2yz (Rec Z (SelectN 
(Send MAIL (Recv R2yz (Rec (S Z) (SelectN 

(Send RCPT (OfferN (Recv R2yz (Var (S Z))) (Recv R5yz (Send QUIT Close)))) 
(Send DATA (Recv R354 (Send MailBody (Recv R2yz (Var Z))))))))) 
(Send QUIT Close))))) 
:> Recv String (Recv String (Select (Recv [String] Close) (Send [String] Close)))) 
(ss :> End :> End) () 

The SMTP protocol is successfully represented in the pre-type of c. A server that have the dual of this 
type can communicate with this client. 

Observe that the two channels are used with no annotation. On the other hand, the implementation 
of fl6| requires the swap operation before and after the each occurrence of d, namely at (1), (2), (3) 
and (4) , and if we add more channels, more complicated bookkeeping operations will be required. 

5 Expressiveness of the encoding based on de Bruijn levels 

We discuss the expressiveness between our implementation and the others. The discussion goes around 
the feature of higher-order sessions originally provided in |6]. We show that the presentation provided in 
|[T6l has some limitation. Due to that fact, our implementation is more expressive than |[T6l . 

At the same time, we sketch that their swap and dig can provide the same expressive power as our de 
Bruijn based solution. 

5.1 The limitation of capability-passing primitive 

The implementation presented in fT6l does not provide primitives for channel-passing, while they pro- 
vide send_cap and recv_cap which communicate the capability of channels. We discuss here that 
capability-passing does not provide full-fledged feature of the higher-order session. 

The primitives send_cap and recv.cap only synchronize on a given channel, but not communicate 
any run-time information. Instead, on the synchronization the sender's side delegates the capability of a 
channel to the receiver's side. 

In several cases this capability-passing is succinct to simulate name-passing. Here we sketch their 
capability-passing primitives by rewriting the code in our implementation using send_cap and recv_cap. 
The following code in our implementation 

pq c = ixdo fork (q c) ; p c 

p c = ixdo d -S— new; throw c d; str -S— recv d; io (putStrLn str) 
q c = ixdo d <— catch c; send d "Hello" 

will be rewritten in their framework as follow^ 

^Assume they provide new and fork primitive in their language. 
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pq' c = ixdo d ^ new; fork (q' c d) ; p' c d 

p' c d = ixdo send_cap c; dig (ixdo str -s— recv d; io (putStrLn str)) 
q' c d = ixdo recv_cap c; dig (send d "Hello") 

Notice that we put the channel-creation primitive (new) before the forking. 

The problem of the capability passing is that the communicated channel must be known before the 
run-time. This is fatal for the distributed application which can not communicate any information before 
run-time. In addition, the Ti-calculus theory says that under the existence of recursion (or replication), 
the rewriting shown above is not possible. See the following code. The process sends fresh channel on c 
repeatedly with sending "Hello" on the thrown channel. 

loop c = ixdo unwind c ; d <— new; throw c d; send d "Hello"; recurl loop c 

The new is now put under the loop. Such repeated channel-creation cannot bring out of the loop, hence 
cannot be expressed in lfT6l . 

5.2 Implementing channel-passing with dig and swap 

The problem of send_cap is that the type-signature of it requires static (type-level) identity of chan- 
nels, which seems to be unneeded constraint with respect to the original Session-type system fSJ. The 
following is the type signature for the both primitives. 

send_cap :: Channel t — )■ Session (Cap t e (Cap t' e' r' :!: r) , (Cap t' e' r', x)) 

(Cap t e r, x) 


recv_cap :: Channel t — > Session (Cap t e (Cap t' e' r' :?: r) , x) 

(Cap t e r, (Cap t' e' r', x)) 


Here, the first arguments of them must have pre-type Cap t e (Cap t ' e ' r ' : ! : r) or Cap t e 
(Cap t' e' r' :?: r) , where t ' denotes identity of communicated channel. 

Since there is no reason to have it, we put the alternative capability type Cap2 e ' r ' which does not 
have identity of a channel. By replacing Cap with Cap2, we get the following signature for sender's side: 

send_chan :: Channel t — > Channel t' 

-)■ Session (Cap t e (Cap2 e' r' :!: r) , (Cap t' e' r', x)) 
(Cap t e r, x) 



On the other hand, the receiver's side is rather complicated. Since the identity of the communicated 
channel was lost at the sender's side, we must give the new one on the receiver's side. That was done 
by introducing an universally quantifying type variable on the signature. Since the type variable cannot 
escape from its scope, the continuation of the process must be given as the second argument. 

recv_chan :: Channel t — > (forall t'. Channel t' — > 

Session (Cap t e r, (Cap t' e' r', x)) 
(Cap t e rr, y) 
) 

Session (Cap t e (Cap2 e' r' :?: r) , x) 
(Cap t e rr, y) 
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6 Other aspects of Session-type implementation 

6.1 Representing recursion of session types 

Many literature on session types takes equi-recursive view of types fTSl, which identifies pLt.T with 
its unfolded form T{iJ.t.T /t}. Unfortunately, Haskell and many other languages do not support such 
typing. Hence ours and the other implementations of session types lfT3l [TTl [T6 1 take different approach, 
iso-recursive view of recursion on types. In this subsection we review each of them. 

The first implementation of recursive session types Ill3]| Neubauer et al. invented a representation 
of recursive type which requires a new type declaration for each session-type recursion. The type Rec is 
a fixpoint type constructor defined as follows: 

newtype Rec f = MkRec (f (Rec f)) 

Rec has kind (*—)•*)—)• *. When a session repeatedly sends integers, the type corresponding to it 
must be declared first: 

newtype G self = G (Send Int self) 

where the type variable self is a placeholder for the recursion variable. By applying Rec on this type, 
the type Rec G is isomorphic to /Xf.Send Int t. 

Such a type is unwound by declaring type classes. Consider expanding Rec G to Send Int (Rec 
G) . A type class RECBODY is declared as follows: 

class RECBODY t c | t ^ c where . . . 

The first type parameter t is for folded form of a recursive type and the second type parameter c is for un- 
folded form. A functional dependency 1 8 ] t — > c declares that Haskell's type checker can automatically 
infer c from t. The expanded form as an instance of RECBODY becomes following: 

instance RECBODY (Rec G) (Send Int (Rec G)) where ... 

However, declaring such types and instances for each recursion seems redundant. As fT3l requires 
another explicit declaration of session types, such redundancy should be avoided. Our implementation 
and the other two implementations do not require such extra declarations. Hereafter we review that of 
ours and Pucella et al., though [ 17] do not give any account of it. 

Expansion of recursive type representations by type-level computation In our implementation, 
such a recursive session type is represented in the form of Rec Z (Send Int (Var Z)). In Rec n 
r a type parameter n denotes the de Bruijn level of the binder and Var n is its occurrence. Then Rec 
Z (Send Int (Var Z)) denotes /xf. Send Int t. The primitive unwind expands the recursion. For 
example, Rec Z (Send Int (Var Z) ) is expanded as Send Int (Rec Z (Send Int (Var Z))). 
The other primitive recurl / c is behaviourally equal to/c, yet this ensures that the pre-types of the all 
channels other than c is ended. Such annotation is required since sometimes the usage of some channels 
has no explicit end and it cannot be inferred by the typechecker. 

Our encoding depends on Haskell's type-level computation. The encoding by Pucella and Toy |[T6l 
is not limited to Haskell, at a cost of a bit complex representation in types. 
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Deferred expansion of recursion body |[l6l In |fT6]| . a recursive type is represented by using de Bruijn 
indices (not levels) as a binder for recursion variable. Thus, the type for a session which repeatedly sends 
integers is Re c (Send Int (Var Z) ) (note that this Rec is different from previous one). Here Var n 
is a type-level recursion variable, where « is a peano-numeral of the de Bruijn index of the binder. 

Their capability type has the form of Cap t e r where t is type tag ifTTIl and r is a session type. 
The second parameter e represents a stack which is used for bookkeeping during recursion. Note that 
this stack is different from that of multiple channels in Section [3^ 

A recursive type is not immediately expanded, but deferred by using a notational trick. To see this, 
consider expanding a recursive session Cap t e (Rec (Send Int (Var Z) )). The recursion body 
is put at the second parameter, resulting Cap t (Send Int (Var Z),e) (Send Int (Var Z))). 
When one met the recursion variable Cap t (Send Int (Var Z) ,e) (Var Z), the substitution is 
actually done and it becomes Cap t (Send Int (Var Z),e) (Send Int (Var Z)). 

By putting a notational trick, Pucella and Tov succeed to represent session-type recursion in a 
language-independent way. Since our implementation already uses heavy type-level computation, we 
have used full functionality of type-classes to represent recursions in a more direct way. In other words, 
our encoding does not require stacks for recursions. 

6.2 Inter-process Communication 

One notable difference between ours and lIlTl is that the communication primitives in their implemen- 
tation are based on process identities, Pids.. Providing both Fids and channels as communication media 
would be much convenient in view of scalability. However, since their framework requires much of 
annotations, usage of channels would become burden. 

In [ 17 1, a typical inter-process communication example that a process parent forks a process child 
to send an integer 52 is written as follows: 

(st, a) = makeSessionType ( 

newLabel ->>= Aa — > 

a .— recv int ~>> send bool ~>> end ~>> 
sreturn a) 

where 

int — undefined : : Int 
bool = undefined : : Bool 

parent = fork a dual (cons (a, notDual) nil) child 
~»=A(_, childPid) 
createSession a dual childPid 
~»= AchildCh 

withChannel childCh (ssend 52 ~» srecv) 
sliftID . print 

child _ parentPid 

= createSession a notDual parentPid 
->>= AparentCh — > 
withChannel parentCh 

(srecv ->>= ssend . ((==) 42)) 

where a is the value-level session type associated to the channel, st is the session type associated to a 
Pid, which is not used. The values dual and notDual is needed because the framework does not infer 
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which side of the protocol it uses. Actual communication is described at the second argument of each 
call of withChannel. 

This complication arises in order to maintain type-level symbol tables. Comparing with this, the 
same behaviour can simply be described in our framework as follows: 

parent = ixdo 
ch -S— new; 
fork (child ch) 

send ch 52 >>> recv ch >>>= io . print 
child ch = recv ch >>>= send ch . ((=) 42) 

Thanks to inference of the symbol table based on de Bruijn levels, our encoding requires essential com- 
munication primitives around the session type. 



7 Usability 

Here we discuss a few aspects of session type implementation. 



Trade-offs between type inference and manual construction of session types As we have shown in 
Section 3.4 annotations required by our implementation is not more than any of the other implementa- 
tions. However, there seems to be a few advantages in 1 17] in a few points. (1) Recursion of a session 
type is treated more naturally in ifTTl . By using term- level operation for constructing session types, lIlTl 
offers more readable formulation of recursion via labels. As you can observe in the SMTP example of 
the previous section, recursion on a session type require a few of not so intuitive annotations unwind, on 
the term-level to represent a recursive protocol. (2) Manual construction of session types in term-level 
offers chance of subtyping. It is difficult to allow subtyping of session types in the parallel composition, 
because of our bijective encoding of duality to extract more information in a parallel composition of a 
session. 



Readability of type error messages If the duality check of two session types fails, the type error 



would be reported. For example, by replacing the occurrence of an integer 456 in Section 3.2.2 with a 
string "456", the following error is obtained 

examples/ calc . hs : <xx> : : 

Couldn't match expected type '[Char]' against inferred type 'Int' 
Expected type : tt ' : > Send [Char] a 

Inferred type: tt' :> Send Int (Select (Recv Int End) (Recv Bool End)) 
When generalising the type(s) for 'plus' 

The error reports that the inferred pre-type of client is not compatible with the expected one. The 
position <xx> of the reported error is not at send c "456" itself, but at the position where the dual of the 
session type is calculated, namely the occurrence of the fork. Thus, this error message directly shows 
which session types are not compatible. Even the type-level hackery we depend tends to produce large 
type signatures, the type eiTor itself can be concisely represented. 



^Here, [Char] is a type synonym of String. 
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8 Concluding remarks 

This paper showed a Haskell implementation of the session-type inference. Our implementation infers 
session types fully automatic without any manual operations such as stack operations in ([TQ. 

The treatment of binders is the key issue for embedding one language into another, as stated in 
ll2l . In our implementation, we took a separated approach for the term-level computation and type- 
level (compile-time) computation. In the term-level computation, a fresh channel is represented by A- 
abstraction (the technique usually called Higher order abstract syntax), utilizing the power of variable- 
bindings in the host language of Haskell. In the type-level computation, de Bruijn levels represent in 
channel types to compare names. These are the key to automate the session-type inference. However, 
since the current technique depends on the type-level programming functionality of Haskell, it is not easy 
to export this technique to the other programming languages yet. 

Our technique using de Bruijn level can be applied to other substructural type systems for the n- 
calculus, such as linear type systems and multiparty session types Q. In particular, encoding of mul- 
tiparty session types is promising. The end-point session types of f7\ is much similar with the original 
binary session types [6], hence our technique can be effectively used. In Haskell, types cannot have 
different concrete representation of types since Haskell's type inference goes through unification. How- 
ever, due to asynchronous nature of multiparty session types, a end-point type k{U);k' {U');T can have 
different concrete representation k' {U');k{U);T ifk^k' where two first components can be exchanged. 
To express such type in a unique form, again our de Bruijn encoding of channels might play a key 
role. That is, ordering such asynchronous sequencing by the de Bruijn level, one can obtain the unique 
representation of a end-point type. Yet much remains to be done in making such ideas in a real code. 

Acknowledgments The first author thanks his colleagues in IT Planning Inc. for supporting him 
during the writing of this paper. This work was partially supported by the Grant-in-Aid (Scientific 
Research (B) 20300009 and Scientific Research(C) 19500026) from the Ministry of Education, Culture, 
Sports, Science, and Technology of Japan. 



References 

[1] Robert Atkey (2009): Parameterized Notions of Computation. Journal of Functional Programming 19(3-4), 
pp. 335-376, doi:10.1017/S095679680900728X 

[2] Brian E. Aydemir, Aaron Bohannon, Matthew Fairbairn, J. Nathan Foster, Benjamin C. Pierce, Peter 
Sewell, Dimitrios Vytiniotis, Geoffrey Washburn, Stephanie Weirich & Steve Zdancewic (2005): Mecha- 
nized Metatheory for the Masses: The PoplMark Challenge. In: Theorem Proving in Higher Order Logics, 
Lecture Notes in Computer Science 3603, Springer- Verlag, pp. 50-65, doi: 10. 1007/1 1541868_4 

[3] Bjorn Bringert, Anders Hockersten, Conny Andersson, Martin Andersson, Mary Bergman, Victor Blomqvist 
& Torbjom Martin (2004): Student paper: HaskellDB improved. In: Haskell '04: Proceedings of the 2004 
ACM SIGPLAN workshop on Haskell, ACM, pp. 108-1 15, doi: 10. 1 145/1017472. 1017473 

[4] Mario Coppo, Mariangiola Dezani-Ciancaglini & Nobuko Yoshida (2007): Asynchronous Session Types and 
Progress for Object Oriented Languages. In: Formal Methods for Open Object-Based Distributed Systems, 
Lecture Notes in Computer Science 4468, Springer- Verlag, pp. 1-3 1 , doi ] 10. 1007/978-3-540-72952-5-1] 

[5] Marco Giunti, Kohei Honda, Vasco T. Vasconcelos & Nobuko Yoshida (2009): Session-Based Type Disci- 
pline for Pi Calculus with Matching. In: In the preproceedings of PLACES '09: Programming Language 



Approaches to Concurrency and Communication-cEntric Software. Available at http : //placesOQ . di . 
[f c.ul.pt/[ ~ 



Imai, Yuen, and Agusa 



91 



[6] Kohei Honda, Vasco T. Vasconcelos & Makoto Kubo (1998): Language Primitives and Type Discipline 
for Structured Communication-Based Programming. In: ESOP '98: Proceedings of the 7th European 
Symposium on Programming, Lecture Notes in Computer Science 1381, Springer- Verlag, pp. 122-138, 
doifT0:i007/BFb0 053567l 

[7] Kohei Honda, Nobuko Yoshida & Marco Carbone (2008): Multiparty Asynchronous Session Types. SIG- 
PLAN Notices 43(1), pp. 273-284, doi: 10.1 145/1328438.1328472 

[8] Mark P. Jones (2000): Type Classes with Functional Dependencies. In: ESOP '00: Proceedings of the 9th Eu- 
ropean Symposium on Programming Languages and Systems, Springer- Verlag, pp. 230-244, doi jl0.l007/3-] 
540-46425-5_15 



[9] Oleg Kiselyov (2006): Simple variable-state monad. Available at http : //www . haskell . org/pipermail/ 



haskell/2006-December/018917.html Mailing list message. 



[10] Oleg Kiselyov, Ralf Lammel & Keean Schupke (2004): Strongly Typed Heterogeneous Collections. 
In: Haskell '04: Proceedings of the ACM SIGPLAN workshop on Haskell, ACM Press, pp. 96-107, 
doiHOl 145/1017472.1017488 

[11] Oleg Kiselyov & Chung C. Shan (2008): Lightweight monadic regions. In: Haskell '08: Proceedings of the 
first ACM SIGPLAN symposium on Haskell, ACM, pp. 1-12, doi: 1071145/141 1286. 141 1288 

[12] Daan Leijen & Erik Meijer (2001): Parsec: Direct Style Monadic Parser Combinators for the Real World. 

Technical Report, Departement of Computer Science, Universiteit Utrecht. Available at http: //www. cs^ 

|uu ■ ni/~daeLn/parsec . html[ 
[13] Matthias Neubauer & Peter Thiemann (2004): An Implementation of Session Types. In: PADL'04 : Practical 

Aspects of Declarative Languages, Lecture Notes in Computer Science 3057, Springer- Verlag, pp. 56-70, 

doi fiaT007/978-3-540-24836-l_5l 

[14] Frank Pfenning & Conal Elliot (1988): Higher-Order Abstract Syntax. In: PLDI '88: Proceedings of the 
ACM SIGPLAN 1988 conference on Programming Language Design and Implementation, ACM Press, pp. 
199-208, doi: 10.1 145/53990.54010 

[15] Benjamin C. Pierce (2002): Types and Programming Languages. MIT Press. 

[16] Riccardo Pucella & Jesse A. Tov (2008): Haskell Session Types with (Almost) No Class. In: 
Haskell '08: Proceedings of the first ACM SIGPLAN symposium on Haskell, ACM Press, pp. 25-36, 
doi fToTl 145/14 1 1286TT4TT290 

[17] Matthew Sackman & Susan Eisenbach (2008): Session Types in Haskell: Updating Message Passing for the 



21st Century. Technical Report, Imperial College London. Available at http://pubs.doc.ic.ac.uk/ 
, session-types- in-haskell/, 



